home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / dviware / beebe / doc / 01readme.txt < prev    next >
Text File  |  1990-10-02  |  6KB  |  112 lines
  1.         Changes to the Public Domain DVI Driver Family
  2.                  for
  3.              IBM PC Microsoft Version 5.0
  4.                  [17-Nov-87]
  5.  
  6. Version 5.0 of Microsoft C finally arrived 13-Nov-87, and I spent the
  7. weekend revising Make to work with this compiler.  Previously,
  8. because of the use of non-standard library functions, it worked only
  9. with Wizard C (now defunct, but forming the basis of Borland
  10. International's Turbo C).  Unfortunately, it would work only in the
  11. small memory model, which in practice limited it to Makefiles of
  12. about 150 lines or less.  This was very inconvenient for the TeX DVI
  13. driver family, which required 5 separate Makefiles.  The new version
  14. of Make now works correctly with Microsoft C Version 5.0, removes
  15. some serious size limitations of the old one, and introduces several
  16. new features; they are described in a 00README.TXT file in the PCMAKE
  17. directory.
  18.  
  19. Microsoft C Version 5.0 is now essentially completely conformant with
  20. October 1986 draft ANSI C.  Version 4.0 supported draft ANSI C
  21. function prototypes only with type names, not variable names; Version
  22. 5.0 eliminates this.  Version 4.0 did not support const and volatile
  23. type modifiers; 5.0 does.    In Version 4.0, function type checking was
  24. selected by defining the preprocessor variable LINT_ARGS; it is
  25. enabled by default with Version 5.0.  The Version 5.0 library also
  26. conforms to draft ANSI C.
  27.  
  28. The addition of draft ANSI C library conformance changes the types of
  29. a number of functions and arguments, so type declarations have been
  30. modified in gblprocs.h.  Previously, the DVI drivers had a single
  31. flag, ANSI, which previously selected ANSI function prototype
  32. declarations.  This has now been replaced by two, ANSI_LIBRARY, to
  33. indicate library conformance, and ANSI_PROTOTYPES, to indicate
  34. support for function prototypes.  Variable names are NOT used in
  35. these prototypes, so the code will still compile with Version 4.0.
  36.  
  37. Version 4.0 supported two interfaces to the compiler, MSC and CL.
  38. MSC was the only one available in Version 3.0, so I continued to use
  39. it.  Version 5.0 drops MSC and provides only CL.  The Makefile has
  40. been revised to reflect this.
  41.  
  42. A few more missing type casts have been installed in the code.
  43. The number of data conversion warning messages has been drastically
  44. reduced by the discovery that a declaration  "float x = 1.0" always
  45. produces a warning, but "double x = 1.0" does not.  The Makefile has
  46. been revised to define float to be double for all the code.  The
  47. warnings that remain (about 3 in each driver, instead of dozens)
  48. appear to possibly be compiler artifacts.  More experimentation is
  49. still required.
  50.  
  51. Besides full draft ANSI C conformance, Version 5.0 introduces some
  52. new optimization levels, and in-line expansion of some important
  53. library functions from the strxxx and memxxx classes.  I am happy to
  54. report that these seem to work successfully with the DVI drivers, and
  55. optimization level -Oailt is now the default, instead of -Od (no
  56. optimization).   Despite the in-line expansion, the .EXE files are 3K
  57. to 7K bytes shorter than they were with Version 4.0.
  58.  
  59. Except for the scanf() bug which affects the -o#:#:# option
  60. (documented in the user manual), it looked like Version 4.0 had no
  61. other bugs which affected the drivers.  However, in October 1987, we
  62. found a bug which can be reproduced by a very simple example: the TeX
  63. file containing just 
  64.  
  65. $VW$
  66. \bye
  67.  
  68. prints V and W correctly, while
  69.  
  70. $WV$
  71. \bye
  72.  
  73. prints V correctly, but produces a black blob for W.   Some length
  74. sessions with Codeview revealed that in the second case, the call to
  75. fseek() in charpk() to position to the bitmap for W was returning a
  76. success status, but not positioning correctly.  In fact, subsequent
  77. getc() calls returned EOF!  End-of-file is not intentionally not
  78. checked for, because in that code section, it cannot happen (unless
  79. the  compiler or library are in error).   Since EOF has the value -1,
  80. or 0xFFFF, this produced a bitmap with all bits set to one, and a
  81. black blob resulted.  Further experimentation showed that a rewind()
  82. issued at the end of readfont() could remove that error, and should
  83. be otherwise harmless, even if it is correctly unnecessary.
  84. With Version 5.0, the bug is no longer there!
  85.  
  86. A version of qsort() has been added for texidx.   keytst has been
  87. updated for convenience, and a version of sleep() added to it so that
  88. it can be run under PC DOS.
  89.  
  90. LINK 3.61 supplied with Microsoft C Version 5.0 supports two new
  91. options, /FARCAL and /PACKCODE, which cause the linker to try to
  92. combine code segments, and replace far calls by near calls, in an
  93. effort to speed up the code.  I have not yet experimented with this.
  94.  
  95. Stack size for programs on the IBM PC remains a thorny issue.
  96. Experimentation with EXEMOD and DVIALW showed that DVIALW would run
  97. with a stack size of 5000 (hex) or larger, but not 4800 (hex) or
  98. less.  I have reduced stack size in MAKEFILE.MSC to 8000 (hex), and
  99. now set it with a LINK option, instead of having to run EXEMOD
  100. separately.  With the new Make, a new rule for producing the .SYM
  101. file has been introduced, shortening the makefile.
  102.  
  103. One user has reported having downloaded DVI files and font files from
  104. a host that stored them as fixed blocked binary records, with the
  105. last (short) block null-padded.  The DVIxxx.EXE files as distributed
  106. will not handle this.  However, code is there in readgf.h and
  107. readpxl.h to handle this case under OS_VAXVMS; just change the "#if
  108. OS_VAXVMS" to "#if (OS_PCDOS | OS_VAXVMS)".  I have not done this in
  109. the master distribution, because I regard such incorrect padding as an
  110. operating system defect.  Users who download fonts from Unix or
  111. TOPS-20 systems will not experience such problems.
  112.